A. Kubernetes Architecture 


1. Worker Node (Node) 


Node —> Physical or virtual machine where containers are deployed. 


(One or more) Pods —> Wrapper around containers, we interact and manage containers through 
pods 


(One or more) Containers —> Runtime environment for containerized applications. Containers run 
microservices and are not ideal for monolithic applications. 


Multiple worker nodes connected to the same network form a cluster 


Master 


2. Master (consists of 4 components) 


a. API server -> Gate keeper of the entire cluster. It validates and configures API objects 
(Pods, services, replication controllers, deployments etc). Kubectl and Ul interact with the 
API. 

b. Scheduler -> Physically schedules pods across multiple nodes based on the constraints 
mentioned in the configuration file. 

c. Control Manager -> Includes Node controller, replication controller, endpoint controller, 
service and token controllers. These controllers are responsible for overall health of entire 
cluster. 

d. etcd -> Distributed key-value database. It stores the current cluster state at any point of 
time. Any kubernetes component can query the etcd to understand the state of the 
cluster. 


Scheduler 
- : Kubelet 
API Server 
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Manager 


kubectl | 


Some more components of Worker node: 


Kubelet -> It runs on each worker node and monitors the health of that node. It ensures that 
containers described in the specification (fetched from API on Kubernetes master) are running and 
healthy. 


Kube-proxy -> It is responsible for maintaining the internetwork of configuration. It maintains the 
distributed network across all the nodes, across all the pods and across all containers. 


Kubernetes Architecture 


kubectl ` 
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Master : Worker Node 


B. Different ways of installing Kubernetes: 


1. Play-with-k8s: https://labs.play-with-k8s.com 
2. Minikube 

3. Kubeadm 

4. Googlr Kubernetes Engine (GKE) 

5. Amazon EKS 

6. Azure Kubernetes Service 


C. Kubectl commands 


Syntax: kubectl [command] [TYPE] [NAME] [flags] 


Kubectl: Syntax 


kubectl [command] [TYPE] [NAME] [flags] Ex: kubectl get pod nginx-pod -w 
D EE EE 
Create pod(s) OR 
get deployment(s) 
describe replicaset(s) 
delete replicationcontroller(s) 
logs service(s) 
exec daemonset(s) 
edit namespace(s) 
run persistentvolume(s) 
apply persistentvolumeclaim(s) 
scale job(s) 
Cronjob(s) 


1. Create: 
To create a resource from a file 
S kubectl create -f pod-example.yaml 
S kubectl create -f deploy-example.yaml 
To create a resource from multiple files in a directory 


$ kubectl create -f <directory> 


2. Get: 
To display high level info of resources 
kubectl get [TYPE(s)] [NAME(s)] [FLAGS] — List one or more resources 


S kubectl get pods (display all pods) 


S kubectl get pods <pod-name> (display info of a specific pod) 
S kubectl get pods -o wide 


S kubectl get pods,deploy 


3. Describe: 
To fetch complete details of resources 
S kubectl describe nodes <node-name> 
S kubectl describe pods <pod-name> 


S kubectl describe pods 


4. Delete: 
To delete resources 
S kubectl delete -f pod.yaml 
$ kubectl delete pods,services -I name=<label-name> 


S kubectl delete pods —all 


5. Exec: 
To execute a command against a container in a pod. 
S kubectl exec <pod-name> date 
S kubectl exec <pod-name> -c <container-name> date 


S kubectl exec -it <pod-name> /bin/bash 


6. Logs: 
Print the logs for a container in a pod 
S kubectl logs <pod-name> 


S kubectl logs -f <pod-name> 


D. Pods 


Pod is an atomic unit of scheduling in Kubernetes. 


Pod deployment: Pod manifest file is written which contains container images that we wish to 
deploy and submit it to the API server on the master node. After that API server and scheduler 
components on master node decide and deploy these pods on appropriate worker nodes. 


Each pod should contain only one container. To scale up an application, we replicate the pods to 
create multiple instances of the same app within the same node. In case where worker node has 
insufficient capacity to scale up, another node can be created which contains the same app 
instances (pods). 


API Server 


Manifest 


Multi-container pods: These are rarely used. Sometimes a container requires a helper container to 
perform certain processing. When the app container is created, the helper container also gets 
created and when the app container dies, the helper container also dies because they are part of 
the same pod. These two containers can communicate with each other using a localhost because 
they share the same network namespace plus they share the same storage space as well. 


API Server 


Manifest 


Master 


Pod lifecycle: 


Write a config/manifest file and submit it to the API server on the cluster. It gets scheduled ona 
worker node on a Kubernetes cluster. Once it gets scheduled, it goes to the pending state. 


d 


Pending: In this state, node will download all the container images and start starting the 
containers. It stays in pending state until all containers are up and running. 

Running: Once all containers are up and running, the main purpose of the pod is achieved. 
Succeeded: After running, the pod is shutdown. 

Failed: This stage can only be achieved from pending or running states. If for some reason 
the pod doesn’t start, it moves to the failed state. 


Pod lifecycle 
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Pod Config/manifest: 


# nginx-pod.yaml 


EE 
name: ReplicationController 
labels: = 

ReplicaSet apps/v1 


containers: Deployment apps/v1 
De T 
image: 


---> Stable 


Pod — Create & Display 


READY STATUS RESTARTS 
1/1 0 


READY STATUS RESTARTS NOMINATED NODE 
nginx-pod 1/1 Running  @ <none> 


Pod - Describe 


| # Display all details and events of a pod 
Name: 

Namespace: default 

Priority: (2) 

PriorityClassName: <none> 

Node: 

Start Time: Tue, 28 Aug 2018 07:06:55 +0000 

Labels: 


Annotations: <none> 

Status: 

IP: 

Containers: 
nginx-container: 


From Message 
Scheduled default-scheduler Successfully assigned default/nginx-pod to node1 
Pulling kubelet, node1 pulling image "nginx" 
Pulled kubelet, node1 Successfully pulled image "nginx" 


Pod - Testing 


[schalla ster ~]$ #Pinging Container IP fron 
PING 10.240.1.26 (10.240.1.26) 56(84) bytes of data. 
64 bytes from 10.240.1.26: icmp_seq=1 ttl=63 time=0.387 ms 
64 bytes from 10.240.1.26: icmp seq=2 ttl=63 time=0.361 ms 
64 bytes from 10.240.1.26: icmp_seq=3 ttl=63 time=@.246 ms 
AG 
--- 10.240.1.26 ping statistics --- 
» time 2000ms 
rtt min/avg/max/mdev = 0.246/0.331/0.387/0.063 ms 


[schalla@master $ #Getting a shell to running cont 


# hostname 


# exit 


[schalla@master 


E. Replication Controller 


Ensures that a specified number of pods are running at any time. 


a) If there are excess pods, they get killed and vice versa. 
b) New pods are launched when they fail, get deleted or terminated. 


Replication controllers and pods are associated with “labels”. 


Advantages: 
1. High Availability 


Assume you have two nodes running one instance each of the same pod. For some reason node 2 
fails and the pod running inside it dies along with it., the control manager on the master node 
detects these changes and looks for a healthy node to create the deleted pod again within a short 
time. 


Demo 


Replication Controller — Config 


# nginx-rc.yaml 


name: nginx-rc 


Replication Controller — Create & Display 


Srinatn@maste! j» 
NAME STATUS RESTARTS 
nginx-rc-62vpv Running © 
nginx-rc-fk67w Running © 
nginx-rc-qk4ph Running © 


NAME STATUS RESTARTS 
nginx-rc-62vpv Running 
nginx-rc-fk67w Running 
nginx-rc-qk4ph Running 


Name: nginx-rc 
Namespace: default 


Annotations: <none> 


Labels: app=nginx-app 
Containers: 


Image: nginx 
Port: 80/TCP 
Host Port: @/TCP 
Environment: <none> 
Mounts: <none> 

Volumes: <none> 

Events: 
Type Reason Message 


Replication Controller — Node Fail 


[srinath@master $ kubectl get po -o wide 

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE 
nginx-rc-51b6b 1/1 Running @ 16s 10.240.1.32 nodel <none> 
nginx-rc-164js 1/1 Running @ 16s 10.240.1.33 nodel <none> 
nginx-rc-qrqv7 "Rol Running © 16s 10.240.2.28 node2 <none> 


[srinath@master $ kubectl get nodes 

NAME STATUS ROLES AGE VERSION 
master Ready master 1d Vall 
node1 Ready <none> 1d VA 1152 
node2 NotReady <none> 1d VI 1192 


rinath@master $ kubectl get po -o wide 
NAME READY STATUS RESTARTS IP NOMINATED NODE 
nginx-rc-51b6b 1/1 Running @ 10.240.1.32 <none> 
nginx-rc-164js 1/1 Running  @ 10.240.1.33 <none> 


nginx-rc-qrqv7 1/1 Unknown g 10.240.2.28 <none> 


Replication Controller — Scaling up 


rinath@master ~]$ kubectl scale rc nginx-rc --replicas=5 


rinath@master ~]$ kubectl get rc nginx-rc 
NAME DESIRED CURRENT READY AGE 
nginx-rc 9m 


kubectl get po -o wid 


READY STATUS ` BEST 


Replication Controller — Scaling down 


srinath@maste 
NAME DES 
nginx-rc 


f | D 
IRED CURRENT READY 


Replication Controller — Delete 


inath ister 


No resources found. 


[srinath@master i 
No resources found. 


Replication controllers are old, ReplicaSets are the new standard. 


F. ReplicaSets 


Ensures that a specified number of pods are running at any time. 


a) If there are excess pods, they get killed and vice versa. 
b) New pods are launched when they fail, get deleted or terminated. 


Replication controllers and pods are associated with “labels”. 


ReplicaSet is next-gen replication conrtroller. 


Replication Controller -> Equality-based selectors 


ReplicaSet -> Set based selectors 


Labels & Selectors: 


We define labels under metadata of pod’s config-file. Labels are key-value pairs that are generally 
attached to pods. Controllers and services manage these pods using selectors. There are two types 
of selectors — Equality based and set based. Equality based selectors are old hence set based 


selectors are practiced often. 


Equality-based 


Operators: 


Examples: 
environment = production 
tier != frontend 


Command line 


$ kubectl get pods -l environment=production 


In manifest: 


environment: production 
tier: frontend 


A Supports: Services, Replication Controller 


Set-based 


Operators: 
in notin’ exists 


Examples: 


environment in (production, qa) 
tier notin (frontend, backend) 


Command line 


$ kubectl get pods -l ‘environment in (production) 


In manifest: 


matchExpressions: 
- {key: environment, operator: In, values: [prod, qa}} 
- {key: tier, operator: Notin, values: [frontend, backend]} 


A Supports: Job, Deployment, Replica Set, and Daemon Set, 


Older resources like replication controllers and services don’t need ‘matchLabels’ field in their 


manifest file for selectors. 


‘matchLabels’ supports on newer resources such as replicasets, deployments, jobs, daemonsets. 


ReplicaSet- Manifest file 


name: nginx-rs 


3 


ReplicaSet- Create & Display 


| srinatn@mastet 

NAME STATUS RESTARTS 
nginx-rs-62vpv Running @ 
nginx-rs-fk67w Running @ 
nginx-rs-qk4ph Running © 


rinatn@mastet v |: 
NAME STATUS RESTARTS 
nginx-rs-62vpv Running 
nginx-rs-fk67w Running 
nginx-rs-qk4ph Running 


ReplicaSet- Describe 


DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR 
3 3 3 14s nginx-container nginx 


Name: nginx-rs 
Namespace: default 


Annotations: <none> 


/ © Waiting / @ Succeeded / @ Failed 
Pod Template: 
Labels: app=nginx-app 
Containers: 
nginx-container: 
Image: nginx 
Port: 80/TCP 
Environment: <none> 
Mounts: <none> 
Volumes: <none> 
Events: 
Type Reason Message 


ReplicaSet — Scheduling 


srinath@master 
NAME READY STATUS RESTARTS IP NOMINATED NODE 
nginx-rc-51b6b 1/1 Running @ 10.240.1.32 <none> 
nginx-rc-164js 1/2 Running @ 10.240.1.33 <none> 
1/1 Running @ 10.240.2.28 <none> 


star 


NAME STATUS ROLES VERSION 
master Ready master NU 
node Ready <none> Vi 

<none> v1.11.2 


NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE 
nginx-rc-51b6b 1/1 Running @ 11m 10.240.1.32 nodel <none> 
nginx-rc-164js 1/1 Running © 11m 10.240.1.33 nodel <none> 


ReplicaSet — Scaling up 


rinath@maste 


aster 
NAME DESIRED CURRENT READY 
nginx-rc 


rinath@ma i 
NAME READY STATUS RESTARTS 
nginx-rc-2x2kg 1/1 Running @ 
nginx-rc-7kvhl 1/1 Running @ 


nginx-rc-wvmrx 1/1 Running 


ReplicaSet — Scaling down 


NAME DESIRED CURRENT READY 


nginx-rc 


RESTARTS 


NAME STATUS 

nginx-rc-2x2kg Running 
nginx-rc-jgt28 Running 
nginx-rc-wvmrx Running 


ReplicaSet — Delete 


[srinath@master 


No resources found. 


IP 
10.240.1.173 
10.240.2.3 


10.240.2.4 


IP 
10.240.1.173 
10.240.1.3 
10.240.2.4 


NODE NOMINATED NODE 
nodel <none> 
node2 <none> 


<none> 


NODE NOMINATED NODE 
nodel <none> 
node1 <none> 
node2 <none> 


G. Deployments 
Deployment is a controller. Deployment is all about updates and rollbacks. 
Features: 


1. Multiple Replicas: Using deployment you can create multiple replicas of pods for high 
availability and load balancing. 

2. Upgrade: 4 strategies — 

- Recreate (switching from version A to version B with a downtime) 

- Rolling update (Ramped or incremental — used by Kubernetes as default method) 

- Canary (gradually shifting production traffic from version A to version B) 

- Blue/Green (version B which is green is deployed alongside version A which is blue with 
exactly same amount of instances. The traffic is shifted from version A to version B at 
the load balancer level. Advantage: instant rollout and rollback) 

3. Rollback: If something goes wrong with the current upgrade then, deployment controller 
will allow you to rollback to previous stable upgrade. 

4. Scale up or scale down: Once you deploy the application, you can scale up or scale down 
the application instances based on the load. For this, update the replica field in 
deployment manifest file accordingly. 

5. Pause and resume: You can pause the deployment process in progress as and when 
needed. Used to test and validate new versions of the feature. 


Demo 


Deployments - Manifest file 


# Deployment 
apps/v1 
Deployment 
name: nginx-deploy 
labels: 
app: nginx-app 


replicas: 3 
selector: 
matchLabels: 

app: nginx-app 

template: 
metadata: 

labels: 
app: nginx-app 

spec: 

containers: 

- name: nginx-container 
image: nginx:1.7.9 
ports: 

- containerPort: 80 


Deployments — Create & Display 


srinath@master $ 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
nginx-deployment 1m 


[srinath@maste “|J 
NAME DESIRED CURRENT READY 
nginx-deployment-c75f4bb64 


inath 


NAME READY STATUS RESTARTS 
nginx-deployment-c75f4bb64-h7hph 1/1 
nginx-deployment-c75f4bb64-pbmj4 í 
nginx-deployment-c75f4bb64-sr4vt 1/1 


Deployments — Describe 


Namespace: default 
CreationTimestamp: Wed, 29 Aug 2018 11:39:31 +0000 


Annotations: deployment.kubernetes.io/revision=1 


RollingUpdate 


Labels: app=nginx-ar 
Containers: 


Conditions: 
Type Status Reason 
Available True MinimumReplicasAvailable 
Progressing True NewReplicaSetAvailable 
OldReplicaSets: <none> 
NewReplicaSet: nginx-deployment-c75f4bb64 (3/3 replicas created) 
Events: 
Type Reason Age From Message 


Deployments — Update Deployment 


Deployments — Rollback Deployment 


deployments "nginx-deployment" 


srinath@master ~]$ 


Deployments — Scaling up 


Deployments — Scaling down 


Deployments — Delete 


H. Services 


Service is a way of grouping of pods that running on the cluster. Services are cheap and you can 
have as many services as possible within your cluster. Services provide some of the important 
features that are standardized across the cluster such as load balancing, service discovery between 


apps. 


192.168.1.1 


p: webserver 


fa 


Types of services: 


1. Cluster IP service: It is reachable only within the cluster. The scope of cluster IP is confined 
to the cluster 

2. NodePort: When you want to expose an app to the outside world on the internet. 

3. LoadBalancer: To distribute incoming traffic over the available nodes to avoid overloading 
certain nodes and leaving others unused. 


|. Volumes 


Pods are ephemeral and stateless. 
Volumes bring persistence to pods. 
Adv of Kubernetes volumes vs Docker volumes: 


- Container has access to volumes 

- Volumes are associated with lifecycle of pod whereas in docker they are associated 
with lifecycle of a container. 

- Kubernetes Supports multiple types of volumes 

- Kubernetes volumes are much more mature and robust. 


Volume categories: 


1. Ephemeral: Same lifetime as pods 
2. Durable: Beyond pods lifetime 


Volume types: 


configMap 

emptyDir 
gcePersistentDisk 
hostPath 
persistentVolumeClaim 
secret 


DE D Nr 


emptyDir: 


- Creates empty directory first created when a Pod is assigned to a Node 
- Stays as long as pod is running 
- Once pod is removed from a node, emptyDir is deleted forever. 


Use cases: Temporary space 


emptyDir - Config 


# test-ed.yaml 
SL 
Pod 


name: test-ed 


image: k8s.gcr.io/test-webserver 
name: test-container 
volumeMounts: 
- name: cache-volume 

mountPath: /cache 


name: cache-volume 


emptyDir — Create & Display 


[srinath@master $ kubectl create -f test-ed.yaml 
pod/test-ed created 


[srinath@master $ kubectl get po 
NAME READY STATUS RESTARTS AGE 
test-ed 1/4 Running 0 49s 


rinath@master |$ kubectl exec test-ed df /cache 
Filesystem 1K-blocks Used Available Use% Mounted on 
/dev/sdal 10474496 5389664 5084832 52% /cache 


emptyDir — Describe 


kubectl describe pod test-ed 
Name: test-ed 
Namespace: default 
Priority: E 
PriorityClassName: <none> 
Node: node2/10.128.0.7 
Start Time: Thu, 30 Aug 2018 13:39:17 +0000 
Labels: <none> 
Annotations: <none> 
Status: Running 
IP: 10.240.2.162 
Containers: 
redis-container: 
Container ID: docker://bb2c13c35729e303428e30fe4aa06e724d1b9ef78677187af41082d763aab705 
Image: redis 


che from cache-volume (rw) 


/var/run/secrets/kubernetes.io/serviceaccount from default-token-mdxv9 (ro) 


>lume : 
EmptyDir (a temporary directory that shares a pod's lifetime) 


emptyDir — Delete 


rinath@master f kubectl delete po test-ed 
pod "test-ed" deleted 


hostPath: 


- Mounts a file or directory from the host node’s filesystem into your Pod. 
- Remains even after the pod is terminated. 

- Similar to docker volume. 

- Host issues might cause problem to hostPath 


hostPath — Config 


name: redis-hostpath 


containers: 

- name: redis-container 
image: redis 
volumeMounts: 

- mountPath: /test-mnt 
name: test-vol 
volumes: 
- name: test-vol 

hostPath: 

path: /test-vol 


HostPath — Create and Display 


rinat aster |$ kubectl create -f redis-hostpath.yaml 
pod/redis-hostpath created 


kubectl get po 
READY STATUS RESTARTS AGE IP NOMINATED NODE 
1/1 Running (2) 19m 10.240.2.163 <none> 


rinath@master ~]$ kubectl exec redis-hostpath df /test-mnt 
Filesystem 1K-blocks Used Available Use% Mounted on 
/dev/sda1 10474496 5389740 5084756 52% /test-mnt 


HostPath — From Host to Pod 


Host(node2): 
node2 cd /test-vol 


echo "From Host" > from-host.txt 


t@node: cat from-host.txt 
From Host 


srinath@master ~]$ kubectl exec redis-hostpath cat /test-mnt/from-host.txt 
From Host 


HostPath — From Pod to Host 


From Pod: 


[srinath@master $ kubectl exec redis-hostpath -it -- /bin/sh 
cd /test-mnt 
# echo “From Pod" > from-pod.txt 


# Cat from-pod.txt 
From Pod 


From Host (node-2): 
root@node2 ~]# cd /test-vol 
root@node2 tc vol]# Ils 
from-pod.txt from-host.txt 
root@node2 test-vol]# cat|from-pod.txt 
From Pod 


HostPath — Delete 


inath@master $ kubectl delete po redis-hostpath 
"redis-hostpath" deleted 


pod 


rinath@maste! $ kubectl get po 


No resources found 


[root@node2 ~]# ls /test-vol 
from-pod.txt from-host.txt 


gcePersistentDisk: 


- Volume mounts a Google Compute Engine (GCE) Persistent Disk into Pod. 
- Volume data is persisted after pod’s termination. 
- Read-write only on one node and Read-only on many nodes. 


J. Persistent Volumes 


Persistent volume subsystem provides a standard API for developers and administrators that 
abstract the details of how storage is provided from how it is consumed. 


Persistent volume (PV) — Piece of storage in a cluster 


Persistent Volume Claim (PVC) — Request for storage. Generally developers make this request 
along with read/write permissions. 


Lifecycle of a Persistent Volume: 


1. Provisioning — Administrator creates the storage volumes. These volumes can be any 
storage type such as block, NFS or distributed. 

2. Binding — We bind the storage request to the persistent volume that was provisioned in 
earlier stage. This storage request in Kubernetes is called PVC. 

3. Usage — Once bounded, then Kubernetes creates the pod and application can start using 
the volume in the pod. 

4. Reclaim — Once a user/developer is done using the volume, they can delete the PVC from 
Kubernetes which allows reclaiming of resources. 


There are two ways to provision volumes 


1. Static Provisioning: Admin needs to create PV before developer requests for volume using 
PVC 


Process: 


Storage infrastructure has different types of storage. Admin creates Storage chunks (PVs) of 
different capacities. Developer can create PVCs to request for a PV from this pool. The PVC gets 
bound with the requested PV. Developer can use this bounded PV in the pod. But in case when 
size of requested storage does not match with one in the available pool, developer has to wait till 
admin creates the right size PV. 


Admin 


2. Dynamic Provisioning: When developer creates a storage request, it simultaneously 
provisions the PV and binds it together. 


Process: 


Assume you have a storage infrastructure with different types of storage as shown in the 
image. We don’t create the PVs manually instead we create something known as storage 
classes. Storage classes are a tag given to a storage based on the type of medium in the 
backend. These storage classes are created and maintained by admins and it is a one-time 
process. Developers need not worry about the availability of correct size of PV in the pool, the 
only thing developers need to make sure is the availability of the type of storage they need. 
Once that is confirmed, a developer can create a PVC which in turn creates a respective PV and 
it gets bounded. Once PVC gets bound to the PV, developer uses the claim inside the pod. 


GlusterFS 


Distributed 


Developer 


K. ConfigMap 


Configuring containerized application: 


- Container images are built to be portable 
- Containers expect configuration from 

o Configuration files 

o Command line arguments 

o Environment variables 


in any of the following format: INI, XML, JSON, custom format. 


ConfigMaps: 


Decouples configuration from pods and components 
Stores configuration data as key-value pairs 
o Configuration files 
o Command line arguments 
o Environment variables 
Similar to secrets but don't contain sensitive information 
- You must create a configmap before referencing it in a pod spec. 


ConfigMaps can be created from directories, files, literals 


Syntax to create a configMap: kubectl create configmap <map-name> <data-source> 


o Path to dir/file: --from file 
o Key-value pair: --from-literal 


Create ConfigMaps from directories 


mkdir -p configure-pod-container/configmap/kubect1/ 


wget https://k8s.io/docs/tasks/configure-pod-container/configmap/kubectl/game.properties -0 
configure-pod-container/configmap/kubect1l/game. properties 


wget https://k8s.io/docs/tasks/configure-pod-container/configmap/kubectl/ui.properties -0 
configure-pod-container/configmap/kubectl/ui.properties 


ls configure-pod-container/configmap/kubectl/ 
game.properties 
ui.properties 


[srinath@master -]$ cat game.properties [srinath@master ~]$ cat ui.properties 
enemies=aliens color. good=purple 

lives=3 color.bad=yellow 

enemies.cheat=true allow.textmode=true 
enemies.cheat.level=noGoodRotten how.nice.to.look=fairlyNice 
secret.code.passphrase=UUDDLRLRBABAS [srinath@master ~]$ 
secret.code.allowed=true 

Secret, code. lives=30 

srinath@master ~]$ 


Create ConfigMaps from directories 


srinath@master:$ kubectl create configmap game-config --from-file=configure-pod- 
container/configmap/kubect1/ 


:$ kubectl get configmaps -o wide 


Create ConfigMaps from directories 


kubectl get configmaps game-config -o yaml 
apiVersion: vi 
data: 
game.properties: |- 
enemies=aliens 
lives=3 
enemies.cheat=true 
enemies.cheat.level=noGoodRotten 
secret. code. passphrase=UUDDLRLRBABAS 
secret.code.allowed=true 
secret.code.lives=30 
ui.properties: | 
color.good=purple 
color.bad=yellow 
allow.textmode=true 
how.nice.to.look=fairlyNice 
kind: ConfigMap 
metadata: 
creationTimestamp: 2018-09-01709:21:427 
name: game-config 
namespace: default 
resourceVersion: "598823" 
selfLink: /api/v1/namespaces/default/configmaps/game-config 
uid: 707531b3-adc8-11e8-b3de-42010a800003 


eating ConfigMaps from-file 


curl -OL https://k8s.io/examples/pods/config/redis-confi 
% Total % Received % Xferd Average Speed Time Time Time Current 
Upload Total Spent Left Speed 
100 185 100 z : $ 3 
10043 100 43 29 C :00:01 0:00:01 


cat redis-config 


maxmemory 2mb 
maxmemory-policy allkeys-lru 


kubectl create configmap example-redis-config --from-file=redis-config 


configmap/example-redis-config created 


Accessing ConfigMaps in 


apiVersion: vi 
kind: Pod 
metadata: 
name: redis 
spec: 
containers: 
- name: redis 
image: kubernetes/redis:v1 
volumeMounts: 
- mountPath: /redis-master 
name: config 
volumes: 
- name: config 
configMap: 
name: example-redis-config 
items: 
- key: redis-config 
path: redis.conf 


Create ConfigMaps from literal values 


inath@master:$ kubectl create configmap special-config --from-literal=special.how=very 


configmap/special-config created 


kubectl get configmaps 


NAME DATA AGE 
special-config 2 2m 


Create ConfigMaps from literal values 


v1 
Pod 


name: test-pod 

containers: 

- name: test-container 
image: k8s.gcr.io/busybox 


command: [ “/bin/sh", "-c" 
env: 


restartPolicy: Never 


$ kubectl logs test-pod | grep SPECIAL 


L. Ingress 


Ingress exposes HTTP and HTTPS routes from outside the cluster to services within 
the cluster. Traffic routing is controlled by rules defined on the Ingress resource. 


Here is a simple example where an Ingress sends all its traffic to one Service: 


cluster 


Paa 


; Ingress-managed : f 
er EEE d d Ingress — routing rule d Service 


load balancer 


An Ingress may be configured to give Services externally-reachable URLs, load balance 
traffic, terminate SSL / TLS, and offer name-based virtual hosting. An Ingress 
controller is responsible for fulfilling the Ingress, usually with a load balancer, though 
it may also configure your edge router or additional frontends to help handle the 
traffic. 


An Ingress does not expose arbitrary ports or protocols. Exposing services other than 
HTTP and HTTPS to the internet typically uses a service of type Service. Type- 
NodePort or Service. Type=LoadBalancer. 


apiVersion: networking.k8s.io/v1 
kind: Ingress 
metadata: 

name: minimal-ingress 

annotations: 

nginx. ingress.kubernetes.io/rewrite-target: / 

spec: 

rules: 

- http: 

paths: 

- path: /testpath 
pathType: Prefix 
backend: 

service: 
name: test 
port: 
number: 80 


M. DaemonSet 
- A DaemonSet ensures that all or some Nodes run a copy of a pod. 
- As nodes are added to a cluster, pods are added. 
- As nodes are removed from the cluster, pods are garbage collected. 


- Deleting a DaemonSet will clean up the pods it created. 


Container 


Cluster 


Master 


Cluster 


Use cases: 


- Node monitoring daemons — ex: collectd 
- Log collection daemons — ex: fluentd 
- Storage daemons — ex: ceph 


Demo: 


DaemonSet — Config file 


apps/v1 
DaemonSet 


name: fluentd-ds 


template: 
metadata: 
labels: 
name: fluentd 
spec: 
containers: 
- name: fluentd 
image: gcr.io/google-containers/fluentd-elasticsearch:1.20 
selector: 


DaemonSet — Create and Display 


kubectl get no 


kubectl create -f fluentd-daemonset.yaml 


kubectl get po -o wide 
READY STATUS RESTARTS AGE NOMINATED NODE 


$ kubectl get ds 


DaemonSet — Describe 


kubectl describe ds fluentd-ds 

Name: fluentd-ds 
Selector: name=fluentd 
Node-Selector: <none> 
Labels: name=fluentd 
Annotations: <none> 
De d Ni of 
Cu t Number of SE 2d: 2 
Number of Nodes Scheduled with Up-to-date Pods: 2 
Number of Nodes Scheduled with Available Pods: 2 
Number of Nodes Misscheduled: @ 
Pods Status: 2 Running Ø Waiting @ Succeede 
Pod Temp e: 

Labels: name=fluentd 

Containers: 

fluentd: 

Image: gcr.io/google-containers/fluentd-elasticsearch:1.20 

Events: 
Type Reason Message 


DaemonSet — Delete 


[srinath@master $ kubectl delete ds fluentd-ds 
daemonset.extensions “fluentd-ds" deleted 


kubectl get po 
No resources found. 


N. Secrets 


- Secrets are Kubernetes objects to handle small amount of sensitive data which includes 
passwords, tokens or keys. Main aim of secrets is to reduce the risk of accidental exposure of 
confidential information. 


- They are created outside the pod and containers. Secrets have no clue on which pod or container 
it will be used. Once it is created, it can be deployed on any pod any number of times. We do 
create secrets before they can be used anywhere inside the pod manifest file 


- Secrets are stored inside etcd database on Kubernetes master. 
- Size of a secret cannot be more than 1MB. 
- Used in two ways — mounted as volumes or exposed as env variables. 


- Sent only to target nodes where pods are running and demand secrets. Unlike other 
configuration management tools like puppet or ansible where they are broadcasted. 


- Each secret is stored in tempfs volume so that access is restricted to the application in the node. 
An application running in another container cannot access this secret. It is very selective to the 
pod/container that demands this secret hence it cannot be accidentally revealed. 


There are two ways to create secrets: 


- Using kubectl 
- Manually writing manifest files for secrets 


Using Kubectl: Syntax 


kubectl create secret [TYPE] [NAME] [DATA] 


generic e Path to dir/file: --from-file 
e File e Key-Value pair : --from-literal 
+ Directory Se a 7 = = 
+ Literal Value 


| docker-registry 


| 
|tls 


Creating Secret: Kubectl 


echo -n 'admin' > ./username.txt 
echo -n ‘1f2d1e2e67df' > ./password.txt 


kubectl create secret generic db-user-pass --from-file=./username.txt -- 
from-file=./password.txt 


kubectl get secrets 


kubectl describe secrets db-user-pass 


Name: db-user-pass 
Namespace: default 
Labels: <none> 
Annotations: <none> 


Type: Opaque 


Data 


Decoding Secrets 


apiVersion: v1 
data: 


kind: Secret 
metadata: 
creationTimestamp: 2018-09-01T12:46:17Z 
name: mysecret 
namespace: default 
resourceVersion: "616565" 
selfLink: 
/api/v1/namespaces/default/secrets/mysecret 
uid: @51e61ae-adeS-11e8-8d64-42010a800003 
type: Opaque 


Consuming “Secrets” from volume 


Pod 


name: mypod 


name: mypod 
image: redis 
volumeMounts: 
name: foo 
mountPath: "/etc/foo" 
readOnly: true 


name: foo 


Consuming “Secrets” from “Environment Variables” 


kubectl create -f mysecret-pod-env.yaml 


nysecret-pod-env created 


name: secret-env-pod | th DN :$ kubectl get po 


containers: READY STATUS 
- name: mycontainer et IO Running 
image: redis 
env: 
- name: SECRET USERNAME 
valueFrom: 
secretKeyRef: CR PASSWORD=1f2d1e2e67df 
name: mysecret SECR JSERNAME=admir 
key: username 


[E name: SECRET PASSWORD 


valueFrom: 
secretKeyRef: 
name: mysecret 


key: password 


restartPolicy: Never 


kubectl exec secret-env-pod env | grep SECRET 


O. Jobs 


Job is a controller that supervises pods for carrying out certain tasks. 
Two types of jobs: 


1. Run to completion (Jobs) : Primarily used for performing batch processing. Once the job 
manifest file is submitted to the API server, a pod gets created and it will execute a 
task. And when the task is completed, it will shutdown by itself. The moment a pod 
gets exit port 0, then job will move away. Once job is completed, pods will move from 
running state to shutdown state. Kubernetes won’t automatically delete these pods, 
we have to do it manually. Pods in shutdown state do not consume any resources as 
there is no more life to it. 


2. Scheduled (CronJobs): Purpose of cronjob is to perform cleanup and free disk space 
and allocate it after a particular interval of time. 


Run to completion jobs: 


- Each job creates one or more pods. 

- Ensure they are successfully terminated. 

- Job controller restarts or gets rescheduled if a pod or node fails during execution. 
- Can run multiple pods in parallel. 

- Can scale up using scale command 


Use cases: 


- One time initialization of resources such as databases. 
- Multiple workers to process messages in queue. 


Config file 


name: countdown 


template: 


name: countdown 


containers: 
- name: counter 
image: centos:7 
command: 
- “bin/bash" 
- SC 
- “for i in 9 8 7 6 5 4 3 2 1 ; do echo $i ; done” 
restartPolicy: Never 


Create, Display and Test 


Describe 


kubectl describe jobs countdown 
Name: countdown 
Namespace: default 
Selector: controller-uid=5071e78a-ac4e-11e8-b3de-42010a800003 
Labels: controller-uid=5071e78a-ac4e-11e8 -b3de-42010a800003 
job-name=countdown 

Annotations: <none> 
Parallelism: 
Completions: 
C+ rt Time 
Pod Template: 

Labels: controller-uid=5071e78a-ac4e-11e8-b3de-42010a800003 

job-name=countdown 
Containers: 


Events: 
Type Reason Age From Message 


Cleanup 


[srinath@master $ kubectl delete jobs countdown 
job.batch “countdown” deleted 


[srinath@master $ kubectl get po 
No resources found 


